Mobile barcode generation and payment

ABSTRACT

An application on user&#39;s mobile device (having a display screen) generates a one-time use and time-limited barcode on the display when the user enters a PIN. The barcode can be scanned to make purchases at a point of sale (POS).

CROSS REFERENCED TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/414,562, filed on Mar. 30, 2009, which claims priority to U.S.Provisional Application Ser. No. 61/119,328, filed Dec. 2, 2008, thecontent of which are incorporated herein by reference in their entirety.

BACKGROUND Field of the Invention

The present invention generally relates to facilitating financialtransactions and more particularly to facilitating such transactionswith a mobile device.

Related Art

Mobile devices, such as cell phones, are being used by more and morepeople world-wide. In addition to using mobile phones for voice calls,consumers can communicate nearly anytime and anywhere to facilitateinformation access to mobile services and the Internet. Mobile phoneshave also become multimedia computing platforms with integral digitalcameras for taking pictures and video, playing music, recordingconversations, and organizing and planning activities and appointments.

More recently, mobile phones have been used in conjunction with on-linepayment service providers, such as PayPal, Inc. of San Jose, Calif. Withthe ever-increasing popularity of the Internet and of Internet commerce,both consumers and sellers are using the Internet to facilitatefinancial transactions between parties, whether they are individuals orcompanies. In on-line financial transactions, consumers may use anon-line payment provider to transfer money and receive money overelectronic networks, such as the Internet. The money transfer may be forpayment of goods or services. The payment providers supply aninfra-structure, software, and services that enable users to make andreceive payments. Mobile phone users may contract with a paymentprovider to allow the user to make payments over the phone. Typically,this requires the user to open up an application on the phone, such asthrough a web browser. The user then accesses his or her on-line accountby entering requested information, such as a user name, phone number,email, and/or password. Payment information can then be entered andtransmitted to the payment provider, who then transfers funds from theuser's account to the payee's account. A confirmation may then be sentto the payer and/or the payee.

While this service gives the consumer flexibility in paying for servicesanywhere using a mobile phone, the procedure can be cumbersome,time-consuming, and may be prone to fraudulent transfers.

SUMMARY

According to one embodiment, an application on a mobile device having ascreen, such as a cell phone, enables the user to generate a barcode onthe screen, which can be scanned for payment. The barcode is valid for alimited period of time (e.g., one minute) and for a single use. Oncescanned, payment is transferred from the user's account to themerchant's account. In one embodiment, the user first opens up theapplication on the phone, which then presents the user with a screenshowing a phone number associated with the user and a field for the userto enter a password or PIN. After entering a correct password or PIN, abarcode is generated and appears on the screen. The barcode is generatedthrough a payment provider, such as PayPal. Once the barcode isgenerated, a scanner, such as a CCD scanner, scans the barcode at thepoint of sale (POS) or other physical payment location. Funds arededucted from the user's account and transferred to the retailer'saccount. The user may be asked for a signature confirmation. A receiptcan then be generated on the mobile device, and purchases trackedimmediately.

According to another embodiment, a receipt can be displayed on theuser's mobile device for performing a refund transaction. The receipt islocated on the user's mobile device, using any suitable search, such asby date, recent activity, store, etc. The receipt may have been storedas part of a purchase described above. Once located, the receipt, in theform of a scannable barcode, is displayed on the user's device. Thereceipt is then scanned, either by the merchant or user. The returnedmerchandise can be scanned before or after the receipt is scanned. Onceboth the returned merchandise and the receipt are scanned, theinformation is compared to ensure that the receipt matches the returnedmerchandise. If the refund is approved, the payment provider transfersthe appropriate funds from the merchant's account to the user's account.The merchant and/or user may then be given a receipt, eitherelectronically or in printable/paper form.

Other scannable financial products may also be generated, such as avirtual debit/credit card, coupons, and gift cards. If a qualifyingpurchase provides the user with an instant coupon or rebate, those canbe generated as well.

As a result, users can easily and safely pay for transaction using theirmobile phone at any location having a suitable scanning device. The useris provided with an alternate or additional vehicle for payment. Theuser does not need to worry about carrying and managing numerousphysical payment means, such as cards, paper coupons, paper giftcertificates, etc. Purchases can be instantly categorized and trackedvia the phone, and receipts instantly available. For merchants orretailers, this new form of payment may increase sales and volume due tothe ability of consumers to have an easy and new way to purchase items.The cost to merchants and retailers may be minimal, as existing scanningsystems may be used or simply modified.

These and other features and advantages of the present invention will bemore readily apparent from the detailed description of the embodimentsset forth below taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a flowchart showing steps for a user to make a payment from amobile phone according to one embodiment;

FIG. 2A is a flowchart showing steps for a payment provider to enable auser to make a payment from a mobile phone according to one embodiment;

FIG. 2B is a flowchart showing steps for a merchant to perform afinancial transaction from a mobile device according to one embodiment;

FIG. 2C is a flowchart showing steps to enable a user to obtain a refundfrom a receipt on a mobile phone according to one embodiment;

FIGS. 3A and 3B show a barcode generated from a mobile phone accordingto one embodiment; and

FIG. 4 is a system diagram showing various steps performed by differentparties to a payment transaction using a mobile device according to oneembodiment; and

FIG. 5 is a block diagram of one embodiment of a system that can be usedto implement one or more components of the system described herein.

Exemplary embodiments and their advantages are best understood byreferring to the detailed description that follows. It should beappreciated that like reference numerals are used to identify likeelements illustrated in one or more of the figures, wherein showingstherein are for purposes of illustrating exemplary embodiments and notfor purposes of limiting the same.

DETAILED DESCRIPTION

FIG. 1 is a flowchart 100 showing one embodiment for a user to make apayment from a mobile phone. In step 102, a user registers with anon-line payment provider, such as PayPal. Registration can be throughany suitable means, such as accessing the payment provider site andentering the required information. For example, the user may be asked tocreate an account if one has not already been established, or if anaccount is established, to fund the account if needed. The user may thenbe asked to enter the phone number of the mobile phone and a password orPIN, followed by a confirmation of that password or PIN. Once the userhas completed registration, an application can be installed on theuser's registered device, such as a mobile phone. When the user is readyto use the service or application, the user opens up the application atstep 104, such as by tapping on the application icon on the phone. Theuser is then presented with a screen showing two fields, a phone numberfield and a password or PIN field. In one embodiment, the device phonenumber is already entered. Note that other identifier fields may beused, in any suitable combination, as long as the payment provider isprovided sufficient information to authenticate the user. In step 106,the user enters the PIN (or any other requested identificationinformation). If the PIN and phone number are verified by the paymentprovider, the user is presented with a screen showing a barcode.

In step 108, the user presents the barcode image to the merchant. Thismay be at a checkout stand or point of sale (POS) after the user hasfinished shopping and the items (and/or services) for purchase have beenscanned or entered for payment. A total is presented to the user, atwhich point, the user provides the merchant a form of payment. In oneembodiment, the user displays the barcode for the merchant to scan. Themerchant then scans the barcode for payment. In another embodiment, theuser may scan the barcode himself, such as by passing the screen througha scanner. Note that a suitable scanner system and type may be requireddepending on the device showing the barcode. For example, a CCD scannermay be needed to accurately scan a device having a reflective screen,such as on a phone. After scanning, the user may be given the option, instep 110, of confirming the payment, such as with a signature, checkingan “accept” icon, etc.

The merchant is then notified whether the payment was approved. Approvalmay be in the form of the payment provider transmitting, and themerchant receiving, a text message, such as “Approved,” a visualmessage, such as a green light, a verbal message, such as from a live orautomated call to the merchant, or any other suitable indication ofapproval. Denial of the payment may be indicated in similar ways, suchas “Denied,” a red light, etc. Denial of the payment may result fromvarious reasons, such as insufficient funds in the user's account tomake the purchase or payment, an error in reading the barcode, or aninvalid barcode. If the denial is from an error in reading, the merchantmay be notified accordingly and the barcode re-scanned as needed. If thedenial is from an invalid barcode, the barcode may have expired or beenused already. If denied, an indication of the reason may be given to themerchant and/or the user so that the reason can be addressed. Forexample, if the denial is an invalid barcode, the barcode may be scannedagain, or a new barcode may be generated for scanning.

In one embodiment, the barcode generated on the user's phone is validfor only one use (e.g., one confirmed use, where the single use may befrom multiple unsuccessful scans and one successful scan) and a specificamount of time. For example, the barcode may only be valid for 30seconds or one minute after the barcode is generated. This increasessecurity and minimizes misuse or fraudulent use of the barcode.

Assuming the barcode is valid and confirmed, the payment is concluded,and the user is given a receipt at step 112, such as from the merchantterminal in the form of a paper receipt or Short Message Service (SMS)message to the phone. In other embodiments, the user may also view areceipt on the phone and manage or otherwise track the purchase throughthe payment provider. For example, the user may make notes about thepurchase for future reference or send the purchase to anotherapplication. The user can also check previous transactions and view orcancel pending authorizations. Note that in some embodiments, the usercan easily cancel this service completely, such as when the phone islost. For example, the user can simply log onto the payment providersite, enter information to access the account, and then cancel theservice. Another security feature may be that the user is required tofirst unlock the phone before use. This can be done in various ways,such as biometric scan or entering an ID to unlock the phone. For thelatter, the user is then required to enter two passwords or PINS, onefor unlocking the phone and one for accessing the application.

FIG. 2A is a flowchart 200 showing another embodiment of steps for apayment provider to enable a user to make a payment from a mobile phone.In step 202, the user registers for service with the payment provider.The payment provider receives and processes information entered by theuser to create the application and account if necessary. The informationmay include a user name, password, financial information, billingaddress, PIN, security questions and answers, etc. Communication of theinformation may be by any means, such as through the Internet,Bluetooth, or a wired connection, using suitable components such asantennas and processors. Next, the payment provider installs theappropriate application on the user's device in step 204, which can bedone via a web browser. The application may simply be an icon on theuser's device screen. When the user is ready to use the application orservice, the user opens the application and enters requested informationas discussed above. The payment provider receives this information toconfirm the user in step 206. If the information (e.g., phone number andPIN) does not correspond to a registered user, the payment provider maynotify the user accordingly for more chances to login. Once the user isconfirmed, the payment provider accesses the user's account at step 208.

At step 210, the payment provider generates a barcode corresponding tothe user's account. The barcode can be generated with standard softwarefor display on a screen or terminal, such as through a processor runningthe software. The barcode may allow access to all the funds in a user'saccount, only a portion set aside by the user, or be restricted tocertain merchants or products/services. For example, a parent may set upan account for a child with limits and restrictions for use.Restrictions may include a maximum amount per transaction or barcodegeneration, a maximum number of transactions per time period (e.g., weekor month), maximum dollar amount of transactions per time period (e.g.,week or month), and a pre-determined expiration date of the agreement,such that after expiration, the user can no longer generate thebarcodes, unless the user renews the agreement. The barcode may also befor a specific amount, as specified by the user after accessing theapplication. For example, after access, the user may be given an optionof entering the amount, selecting from one of several pre-definedamounts, or using a default amount.

Once the barcode is generated, the payment provider transmits thebarcode to the user device, which displays the barcode on the device.Transmission of the barcode can be by the same or similar means as usedto receive information from the user, e.g., antenna, transmitter, ortransceiver. The payment provider then waits for information from themerchant or scanner. This information may include the merchant's name,account information, payment amount, etc. When the information isreceived at step 212, the payment provider determines whether thereceived information will allow the payment provider to make thetransfer. As discussed above, information that will make the paymentprovider deny the payment can include a requested payment exceeding thebarcode limit, an expired or already used barcode, a barcode notmatching the one for the user, an unrecognized merchant account, etc. Ifthe received information is proper, the payment provider affects atransfer of funds from the user's account to the merchant's account instep 214, with protocols and software executed by processors such asused by PayPal and other on-line financial institutions. The paymentprovider may also send a confirmation to both the user and merchant thatfunds have been transferred. Confirmation may be the same for the userand merchant or different, and may include a text message, a visualindicator, a voice indicator, etc.

In another embodiment, the payment provider may provide an additionallayer of protection for the merchant, e.g., to minimize charge backsand/or obtain proof of user signature or consent. Initially, themerchant scans the generated barcode with a scanner, such as describedabove. The POS software at the merchant location then makes aDoAuthorization API call to the payment provider to authorize thepayment. In response, the payment provider determines whether thescanned information is consistent with the payment provider informationfor the user and responds with an authorization or decline to themerchant. If authorized, the merchant can then display the amount forthe user to authorize. This can be on an electronic signature pad forthe user to sign or just an OK button for the user to press. The POSsoftware then makes a DoCapture API call to the payment provider tocapture the payment. The payment provider will then respond with an APIresponse to indicate whether the funds were transferred successfully. Ifso, the merchant prints a receipt for the user.

FIG. 2B is a flowchart 230 showing steps performed by a merchant forperforming a financial transaction using a mobile device displaying abarcode, according to one embodiment. When a user of a mobile devicedesires to make a financial transaction with the merchant (or anyoneelse), the user generates and displays a barcode on the mobile devicedescribed above. This may be when the user has completed shopping isready to check out or pay for the items at the register or point ofsale. Initially, at step 232, the merchant records the items forpurchase and the total amount owed by the purchaser, such as scanningthe items for both a description and price. Next, at step 234, themerchant is presented with a barcode displayed on the user's orpurchaser's mobile device, such as a phone. The barcode is then scanned,at step 236, either by the merchant or by the user (such as with amerchant scanner). Again, depending on the display/screen of the userdevice, an appropriate scanner is needed to accurately read the barcode,such as a CCD scanner. The barcode information and the purchaseinformation are transmitted to the payment provider at step 238, whichis processed by the payment provider. The merchant then receives anotification that the payment has been accepted or denied, at step 240.If denied, the merchant can inform the user at step 242, and the usercan respond accordingly. Options include scanning the barcode again,generating a new barcode, or presenting the merchant with a new form ofpayment. If accepted, the merchant may receive a confirmation of thetransaction at step 244. As a result, funds are transferred from theuser's account to the merchant's account for the purchase of the desireditem(s).

FIG. 2C is a flowchart 250 showing an embodiment for a user to retrievea receipt on a mobile phone and use that for a refund at a POS. After apurchase, such as described above, the user may want to return thepurchase for a refund. In step 252, the user locates the receipt on theuser's mobile phone or device. The receipt may have been stored as partof the initial purchase, as described above. Retrieval of the receiptmay include the application having a search menu that allows the user tolocate a transaction by the merchant, dollar amount, date, or othercategory. The user can select the desired transaction to view details,such as item and receipt. Once the desired receipt or transaction islocated, the barcode receipt is shown on the display of the mobiledevice in step 254. For example, a button could be added to thetransaction detail page to display the merchant's order ID or invoice ID(represented by the barcode). The barcode receipt may also be displayedor generated in any other suitable manner, such as being captured andstored as a barcode during the purchasing process.

Once displayed, the merchant, at step 256, scans the barcode, as part ofthe refund process. Scanning of the barcode can be done before or afterthe merchant scans the returned merchandise. Next, at step 258, the POSsoftware at the merchant location makes a refund API call to initiatethe refund. In one embodiment, the payment provider can then determineif the transaction (refund) is proper and valid. Ways in which thepayment provider can do this include confirming whether the merchant anduser accounts are valid, matching up the specific merchant account withthe merchant, matching up the specific user account with the user,determining whether the refunded item was truly purchased and if it waspurchased at the merchant, matching the returned item to what isindicated on the receipt, any expiration date on the receipt forrefunds, etc. When the refund is approved, either by the paymentprovider or by the merchant, the payment provider transfers the refundedamount from the merchant's account to the user's account. The paymentprovider then transmits an API response to indicate whether the refundwas successful. If so, the merchant, at step 260, prints a receipt thatshows the refund transaction. The refund receipt may also be stored onthe user's phone. This embodiment enables the user to easily andeffectively manage receipts and refunds, as compared to saving, storing,and categorizing paper receipts.

FIGS. 3A and 3B show one embodiment of a barcode generated from a mobilephone 300. In FIG. 3A, the user has opened up the application and ispresented with a login screen 302. Login screen 302 includes a phonefield 304, which may or may not be populated with the device phonenumber, and a password or PIN field 306, where the user enters his orher PIN, such as using the phone keys. After a successful login, theuser is shown a screen with a barcode 308, which may only be valid for acertain time period and for a single use. The barcode shown on thescreen can then be scanned for payment at a POS, as described above.

FIG. 4 is a diagram showing various steps performed by different partiesto a payment transaction using a mobile device according to oneembodiment. Path 1 illustrates steps taken by a buyer to register withthe payment provider or create an account with the payment provider.Selected information, such as the PIN, phone number, agreement token,and agreement ID are stored in a database 400 of the payment provider.Database 400 may be stored on a local or remote server or any othersuitable storage means. Path 2 shows steps for the buyer when he isready to make a purchase at a store or POS. The user PIN and phonenumber are searched in database 400 to find the matching user ID. Thebarcode is generated, with an associated barcode ID. Both the user IDand barcode ID are stored in database 400. Path 3 shows steps for themerchant after the barcode is generated in path 2. After scanning thebarcode, the barcode ID is checked in the database with a matching userID. When confirmed, the user ID is transmitted to the merchant forconfirmation of payment.

FIG. 5 is a block diagram of a computer system 500 according to oneembodiment, which may be suitable for implementing embodiments ofvarious aspects of this disclosure. In various implementations ofembodiments, device 300 may comprise a personal computing device, suchas a personal computer, laptop, PDA, cellular phone or other personalcomputing or communications devices. Database 400 may be within, partof, or comprise a network computing device, such as one or more servers,computer or processor combined to provide the payment services. Thus, itshould be appreciated that the devices described herein may beimplemented as computer system 500 in a manner as follows.

In one embodiment, computer system 500 may include a bus 502 or othercommunication mechanism for communicating information, whichinterconnects subsystems and components, such as a processing component504 (e.g., processor, micro-controller, digital signal processor (DSP),etc.), a system memory component 506 (e.g., RAM), a static storagecomponent 508 (e.g., ROM), a disk drive component 510 (e.g., magnetic oroptical), a network interface component 512 (e.g., modem or Ethernetcard), a display component 514 (e.g., CRT or LCD for displaying thegenerated barcode), an input component 516 (e.g., keyboard or keypad forentering a PIN or password), and/or a cursor control component 518(e.g., keys, mouse, or trackball). In one embodiment, disk drivecomponent 510 may comprise a database having one or more disk drivecomponents. Network interface component 512 may include an antenna,either separate or integrated, to enable transmission and reception viacommunication link 520.

Computer system 500 may perform specific operations by processor 504executing one or more sequences of one or more instructions contained insystem memory component 506, according to steps described above withrespect to FIGS. 1, 2A, and 2B. Such instructions may be read intosystem memory component 506 from another computer readable medium, suchas static storage component 508 or disk drive component 510. The variousstorage or memory components may be used to store information abouttrusted sources for the quick-approval process. In other embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions to implement the invention.

Logic may be encoded in a computer readable medium, which may refer toany medium that participates in providing instructions to processor 504for execution. Such a medium may take many forms, including but notlimited to, non-volatile media, volatile media, and transmission media.In various implementations, non-volatile media includes optical ormagnetic disks, such as disk drive component 510, volatile mediaincludes dynamic memory, such as system memory component 406, andtransmission media includes coaxial cables, copper wire, and fiberoptics, including wires that comprise bus 502. In one example,transmission media may take the form of acoustic or light waves, such asthose generated during radio wave and infrared data communications.

Some common forms of computer readable media includes, for example,floppy disk, flexible disk, hard disk, magnetic tape, any other magneticmedium, CD-ROM, any other optical medium, punch cards, paper tape, anyother physical medium with patterns of holes, RAM, PROM, EPROM,FLASH-EPROM, any other memory chip or cartridge, carrier wave, or anyother medium from which a computer is adapted to read.

In various example embodiments, execution of instruction sequences forpracticing embodiments of the invention may be performed by computersystem 500. In various other embodiments, a plurality of computersystems 500 coupled by communication link 520 may perform instructionsequences to practice the invention in coordination with one another.

Computer system 500 may transmit and receive messages, data, informationand instructions, including one or more programs (i.e., applicationcode) through communication link 520 and communication interface 512.Received program code may be executed by processor 504 as receivedand/or stored in disk drive component 510 or some other non-volatilestorage component for execution.

Where applicable, various embodiments provided by the present disclosuremay be implemented using hardware, software, or combinations of hardwareand software. Also, where applicable, the various hardware componentsand/or software components set forth herein may be combined intocomposite components comprising software, hardware, and/or both withoutdeparting from the spirit of the present disclosure. Where applicable,the various hardware components and/or software components set forthherein may be separated into sub-components comprising software,hardware, or both without departing from the scope of the presentdisclosure. In addition, where applicable, it is contemplated thatsoftware components may be implemented as hardware components andvice-versa.

Software, in accordance with the present disclosure, such as programcode and/or data, may be stored on one or more computer readablemediums. It is also contemplated that software identified herein may beimplemented using one or more general purpose or specific purposecomputers and/or computer systems, networked and/or otherwise. Whereapplicable, the ordering of various steps described herein may bechanged, combined into composite steps, and/or separated into sub-stepsto provide features described herein.

The foregoing disclosure is not intended to limit the present inventionto the precise forms or particular fields of use disclosed. It iscontemplated that various alternate embodiments and/or modifications tothe present invention, whether explicitly described or implied herein,are possible in light of the disclosure. For example, entry of a userPIN with associated phone number may create a virtual debit card with acorresponding barcode. The barcode can then be scanned for normal debitcard processing. Other examples include generation of barcodescorresponding to coupons, gift cards, or virtually any financialinstrument. Furthermore, the generation and scanning of the barcode canbe at any time during the transaction, such as before, during, or afteritems are scanned or otherwise recorded.

Having thus described embodiments of the invention, persons of ordinaryskill in the art will recognize that changes may be made in form anddetail without departing from the scope of the invention. Thus, theinvention is limited only by the claims.

1. (canceled)
 2. A system, comprising: one or more processors, one ormore computer-readable memories, with program instructions stored on theone or more computer-readable memories, the one or more processorsconfigured to execute the program instructions to cause the system toperform operations comprising: in response to receiving a request froman authenticated user for a scannable payment code, transmittinginformation to the user device to cause the scannable payment code to bedisplayed on the user device, wherein the scannable payment codeincludes information that corresponds to a user account associated withthe user; receiving the scannable payment code from a merchant device ofa merchant in association with a transaction; in response to thereceiving the scannable payment code from the merchant device,determining whether the scannable payment code corresponds with the useraccount of the user; and in response to determining that the scannablepayment code corresponds to the user account of the user, processing thetransaction using the user account.
 3. The system of claim 2, whereinthe operations further comprise: determining that the transactionsatisfies one or more criteria corresponding to the scannable paymentcode; and wherein the processing the transaction using the user accountis further based on determining that the transaction satisfies the oneor more criteria corresponding to the scannable payment code.
 4. Thesystem of claim 3, wherein the determining that the transactionsatisfies the one or more criteria corresponding to the scannablepayment code includes determining that a time that the scannable paymentcode was received from the merchant device corresponds to a time periodof validity associated with the scannable payment code.
 5. The system ofclaim 3, wherein the scannable payment code is configured to be usablefor a transaction amount that is below a pre-defined amount, and whereinthe determining that the transaction satisfies the one or more criteriacorresponding to the scannable payment code includes determining that atransaction amount associated with the transaction is below thepre-defined amount.
 6. The system of claim 3, wherein the scannablepayment code is configured to be usable for a transaction that isassociated with a specific item or service, and wherein the determiningthat the transaction satisfies the one or more criteria corresponding tothe scannable payment code includes determining that an item or serviceassociated with the transaction corresponds to the specific item orservice.
 7. The system of claim 2, wherein the scannable payment codetransmitted is configured to be valid for a single transaction.
 8. Thesystem of claim 2, wherein the operations further comprises: receivingauthentication information from the user device; and authenticating theuser of the user device prior to transmitting the information to theuser device to cause the scannable payment code to be displayed on theuser device.
 9. A method comprising: in response to receiving a requestfrom an authenticated user for a scannable payment code, transmittinginformation to the user device to cause the scannable payment code to bedisplayed on the user device, wherein the scannable payment codeincludes information that corresponds to a user account associated withthe user; receiving the scannable payment code from a merchant device ofa merchant in association with a transaction; in response to thereceiving the scannable payment code from the merchant device,determining whether the scannable payment code corresponds with the useraccount of the user; and in response to determining that the scannablepayment code corresponds to the user account of the user, processing thetransaction using the user account.
 10. The method of claim 9, furthercomprising: determining that the transaction satisfies one or morecriteria corresponding to the scannable payment code; and wherein theprocessing the transaction using the user account is further based ondetermining that the transaction satisfies the one or more criteriacorresponding to the scannable payment code.
 11. The method of claim 10,wherein the determining that the transaction satisfies the one or morecriteria corresponding to the scannable payment code includesdetermining that a time that the scannable payment code was receivedfrom the merchant device corresponds to a time period of validityassociated with the scannable payment code.
 12. The method of claim 10,wherein the scannable payment code is configured to be usable for atransaction amount that is below a pre-defined amount, and wherein thedetermining that the transaction satisfies the one or more criteriacorresponding to the scannable payment code includes determining that atransaction amount associated with the transaction is below thepre-defined amount.
 13. The method of claim 10 wherein the scannablepayment code is configured to be usable for a transaction that isassociated with a specific item or service, and wherein the determiningthat the transaction satisfies the one or more criteria corresponding tothe scannable payment code includes determining that an item or serviceassociated with the transaction corresponds to the specific item orservice.
 14. The method of claim 9, wherein the scannable payment codetransmitted is configured to be valid for a single transaction.
 15. Themethod of claim 9, further comprising: receiving authenticationinformation from the user device; and authenticating the user of theuser device prior to transmitting the information to the user device tocause the scannable payment code to be displayed on the user device. 16.A non-transitory machine-readable medium having stored thereonmachine-readable instructions executable to cause a machine to performoperations comprising: in response to receiving a request from anauthenticated user for a scannable payment code, transmittinginformation to the user device to cause the scannable payment code to bedisplayed on the user device, wherein the scannable payment codeincludes information that corresponds to a user account associated withthe user; receiving the scannable payment code from a merchant device ofa merchant in association with a transaction; in response to thereceiving the scannable payment code from the merchant device,determining whether the scannable payment code corresponds with the useraccount of the user; and in response to determining that the scannablepayment code corresponds to the user account of the user, processing thetransaction using the user account.
 17. The non-transitorymachine-readable medium of claim 16, wherein the operations furthercomprise: determining that the transaction satisfies one or morecriteria corresponding to the scannable payment code; and wherein theprocessing the transaction using the user account is further based ondetermining that the transaction satisfies the one or more criteriacorresponding to the scannable payment code.
 18. The non-transitorymachine-readable medium of claim 17, wherein the determining that thetransaction satisfies the one or more criteria corresponding to thescannable payment code includes determining that a time that thescannable payment code was received from the merchant device correspondsto a time period of validity associated with the scannable payment code.19. The non-transitory machine-readable medium of claim 17, wherein thescannable payment code is configured to be usable for a transactionamount that is below a pre-defined amount, and wherein the determiningthat the transaction satisfies the one or more criteria corresponding tothe scannable payment code includes determining that a transactionamount associated with the transaction is below the pre-defined amount.20. The non-transitory machine-readable medium of claim 17, wherein thescannable payment code is configured to be usable for a transaction thatis associated with a specific item or service, and wherein thedetermining that the transaction satisfies the one or more criteriacorresponding to the scannable payment code includes determining that anitem or service associated with the transaction corresponds to thespecific item or service.
 21. The non-transitory machine-readable mediumof claim 16, wherein the scannable payment code transmitted isconfigured to be valid for a single transaction.